تجسير العوالم: نظرة معمقة على روابط مضيف WebAssembly وتكامل بيئة تشغيل اللغة

ظهر WebAssembly (Wasm) كتقنية ثورية، تعد بمستقبل من التعليمات البرمجية المحمولة وعالية الأداء والآمنة التي تعمل بسلاسة عبر بيئات متنوعة—من متصفحات الويب إلى خوادم السحابة وأجهزة الحافة. في جوهره، Wasm هو تنسيق تعليمات ثنائي لآلة افتراضية قائمة على المكدس. ومع ذلك، فإن القوة الحقيقية لـ Wasm لا تكمن فقط في سرعته الحسابية؛ بل في قدرته على التفاعل مع العالم من حوله. هذا التفاعل، مع ذلك، ليس مباشرًا. إنه يتم بوساطة دقيقة من خلال آلية حاسمة تعرف باسم روابط المضيف.

وحدة Wasm، بحكم تصميمها، هي سجين في بيئة معزولة آمنة. لا يمكنها الوصول إلى الشبكة، أو قراءة ملف، أو التلاعب بنموذج كائن المستند (DOM) لصفحة ويب بمفردها. يمكنها فقط إجراء حسابات على البيانات داخل مساحة الذاكرة المعزولة الخاصة بها. روابط المضيف هي البوابة الآمنة، وعقد واجهة برمجة التطبيقات (API) المحدد جيدًا الذي يسمح لرمز Wasm الموجود في البيئة المعزولة ("الضيف") بالتواصل مع البيئة التي يعمل فيها ("المضيف").

يقدم هذا المقال استكشافًا شاملًا لروابط مضيف WebAssembly. سنقوم بتشريح آلياتها الأساسية، والتحقيق في كيفية تجريد سلاسل أدوات اللغة الحديثة لتعقيداتها، والنظر إلى المستقبل مع نموذج مكونات WebAssembly الثوري. سواء كنت مبرمج أنظمة، أو مطور ويب، أو مهندس سحابة، فإن فهم روابط المضيف هو مفتاح إطلاق الإمكانات الكاملة لـ Wasm.

فهم البيئة المعزولة: لماذا تعتبر روابط المضيف ضرورية

لتقدير أهمية روابط المضيف، يجب على المرء أولاً فهم نموذج أمان Wasm. الهدف الأساسي هو تنفيذ التعليمات البرمجية غير الموثوق بها بأمان. يحقق Wasm ذلك من خلال عدة مبادئ رئيسية:

• عزل الذاكرة: تعمل كل وحدة Wasm على كتلة مخصصة من الذاكرة تسمى الذاكرة الخطية. هذه في الأساس مصفوفة كبيرة ومتجاورة من البايتات. يمكن لرمز Wasm القراءة والكتابة بحرية داخل هذه المصفوفة، لكنه غير قادر هيكليًا على الوصول إلى أي ذاكرة خارجها. أي محاولة للقيام بذلك تؤدي إلى فخ (إنهاء فوري للوحدة).
• الأمان القائم على القدرات: لا تمتلك وحدة Wasm أي قدرات متأصلة. لا يمكنها إجراء أي آثار جانبية ما لم يمنحها المضيف صراحةً الإذن للقيام بذلك. يوفر المضيف هذه القدرات عن طريق كشف الدوال التي يمكن لوحدة Wasm استيرادها واستدعائها. على سبيل المثال، قد يوفر المضيف دالة `log_message` للطباعة إلى وحدة التحكم أو دالة `fetch_data` لتقديم طلب شبكة.

هذا التصميم قوي. وحدة Wasm التي تقوم فقط بإجراء حسابات رياضية لا تتطلب أي دوال مستوردة ولا تشكل أي خطر على الإدخال/الإخراج. يمكن إعطاء وحدة تحتاج إلى التفاعل مع قاعدة بيانات الدوال المحددة التي تحتاجها فقط للقيام بذلك، متبعة مبدأ الامتياز الأقل.

روابط المضيف هي التنفيذ الملموس لهذا النموذج القائم على القدرات. إنها مجموعة الدوال المستوردة والمصدرة التي تشكل قناة الاتصال عبر حدود البيئة المعزولة.

الآليات الأساسية لروابط المضيف

على أدنى مستوى، تحدد مواصفات WebAssembly آلية بسيطة وأنيقة للاتصال: استيراد وتصدير الدوال التي يمكنها فقط تمرير بعض الأنواع الرقمية البسيطة.

الاستيراد والتصدير: المصافحة الوظيفية

يتم تأسيس عقد الاتصال من خلال آليتين:

• الاستيراد (Imports): تعلن وحدة Wasm عن مجموعة من الدوال التي تتطلبها من بيئة المضيف. عندما يقوم المضيف بإنشاء نسخة من الوحدة، يجب عليه توفير تطبيقات لهذه الدوال المستوردة. إذا لم يتم توفير استيراد مطلوب، فسيفشل إنشاء النسخة.
• التصدير (Exports): تعلن وحدة Wasm عن مجموعة من الدوال أو كتل الذاكرة أو المتغيرات العامة التي توفرها للمضيف. بعد إنشاء النسخة، يمكن للمضيف الوصول إلى هذه الصادرات لاستدعاء دوال Wasm أو التلاعب بذاكرتها.

في تنسيق نص WebAssembly (WAT)، يبدو هذا مباشرًا. قد تستورد وحدة ما دالة تسجيل من المضيف:

مثال: استيراد دالة مضيف في WAT

(module (import "env" "log_number" (func $log (param i32))) ... )

وقد تصدر دالة ليقوم المضيف باستدعائها:

مثال: تصدير دالة ضيف في WAT

(module ... (func $add (param $a i32) (param $b i32) (result i32) local.get $a local.get $b i32.add ) (export "add" (func $add)) )

المضيف، الذي يكتب عادةً بلغة JavaScript في سياق المتصفح، سيوفر دالة `log_number` ويستدعي دالة `add` بهذا الشكل:

مثال: مضيف JavaScript يتفاعل مع وحدة Wasm

const importObject = { env: { log_number: (num) => { console.log("Wasm module logged:", num); } } }; const response = await fetch('module.wasm'); const { instance } = await WebAssembly.instantiateStreaming(response, importObject); const result = instance.exports.add(40, 2); // result is 42

هوة البيانات: عبور حدود الذاكرة الخطية

المثال أعلاه يعمل بشكل مثالي لأننا نمرر فقط أرقامًا بسيطة (i32, i64, f32, f64)، وهي الأنواع الوحيدة التي يمكن لدوال Wasm قبولها أو إرجاعها مباشرة. ولكن ماذا عن البيانات المعقدة مثل السلاسل النصية، أو المصفوفات، أو الهياكل (structs)، أو كائنات JSON؟

هذا هو التحدي الأساسي لروابط المضيف: كيفية تمثيل هياكل البيانات المعقدة باستخدام الأرقام فقط. الحل هو نمط سيكون مألوفًا لأي مبرمج C أو C++: المؤشرات والأطوال.

تعمل العملية على النحو التالي:

1. من الضيف إلى المضيف (على سبيل المثال، تمرير سلسلة نصية):
   • يقوم ضيف Wasm بكتابة البيانات المعقدة (على سبيل المثال، سلسلة نصية بترميز UTF-8) في ذاكرته الخطية الخاصة.
   • يستدعي الضيف دالة مضيف مستوردة، ويمرر رقمين: عنوان الذاكرة الابتدائي ("المؤشر") وطول البيانات بالبايت.
   • يتلقى المضيف هذين الرقمين. ثم يصل إلى الذاكرة الخطية لوحدة Wasm (التي يتم كشفها للمضيف كـ `ArrayBuffer` في JavaScript)، ويقرأ العدد المحدد من البايتات من الإزاحة المعطاة، ويعيد بناء البيانات (على سبيل المثال، يفك ترميز البايتات إلى سلسلة JavaScript).
2. من المضيف إلى الضيف (على سبيل المثال، استقبال سلسلة نصية):
   • هذا أكثر تعقيدًا لأن المضيف لا يمكنه الكتابة مباشرة في ذاكرة وحدة Wasm بشكل عشوائي. يجب على الضيف إدارة ذاكرته الخاصة.
   • عادةً ما يصدر الضيف دالة لتخصيص الذاكرة (على سبيل المثال، `allocate_memory`).
   • يستدعي المضيف أولاً `allocate_memory` ليطلب من الضيف حجز مخزن مؤقت بحجم معين. يعيد الضيف مؤشرًا إلى الكتلة المخصصة حديثًا.
   • يقوم المضيف بعد ذلك بترميز بياناته (على سبيل المثال، سلسلة JavaScript إلى بايتات UTF-8) ويكتبها مباشرة في ذاكرة الضيف الخطية في عنوان المؤشر المستلم.
   • أخيرًا، يستدعي المضيف دالة Wasm الفعلية، ويمرر المؤشر وطول البيانات التي كتبها للتو.
   • يجب على الضيف أيضًا تصدير دالة `deallocate_memory` حتى يتمكن المضيف من الإشارة إلى أن الذاكرة لم تعد مطلوبة.

هذه العملية اليدوية لإدارة الذاكرة والترميز وفك الترميز مملة وعرضة للخطأ. خطأ بسيط في حساب الطول أو إدارة مؤشر يمكن أن يؤدي إلى بيانات تالفة أو ثغرات أمنية. هذا هو المكان الذي تصبح فيه بيئات تشغيل اللغة وسلاسل الأدوات لا غنى عنها.

تكامل بيئة تشغيل اللغة: من الكود عالي المستوى إلى الروابط منخفضة المستوى

كتابة منطق المؤشر والطول يدويًا ليست قابلة للتطوير أو الإنتاج. لحسن الحظ، تتعامل سلاسل الأدوات للغات التي تترجم إلى WebAssembly مع هذه الرقصة المعقدة نيابة عنا عن طريق إنشاء "كود لاصق" (glue code). يعمل هذا الكود اللاصق كطبقة ترجمة، مما يسمح للمطورين بالعمل مع أنواع عالية المستوى ومصطلحية في لغتهم المختارة بينما تتولى سلسلة الأدوات معالجة تنظيم الذاكرة منخفض المستوى.

دراسة حالة 1: Rust و `wasm-bindgen`

يتمتع نظام Rust البيئي بدعم من الدرجة الأولى لـ WebAssembly، يتمحور حول أداة `wasm-bindgen`. يسمح بقابلية تشغيل بيني سلسة ومريحة بين Rust و JavaScript.

لنأخذ دالة Rust بسيطة تأخذ سلسلة نصية، وتضيف بادئة، وتعيد سلسلة جديدة:

مثال: كود Rust عالي المستوى

use wasm_bindgen::prelude::*; #[wasm_bindgen] pub fn greet(name: &str) -> String { format!("Hello, {}!", name) }

تخبر السمة `#[wasm_bindgen]` سلسلة الأدوات بأن تقوم بسحرها. إليك نظرة عامة مبسطة على ما يحدث خلف الكواليس:

1. ترجمة Rust إلى Wasm: يقوم مترجم Rust بترجمة `greet` إلى دالة Wasm منخفضة المستوى لا تفهم `&str` أو `String` الخاصة بـ Rust. سيكون توقيعها الفعلي شيئًا مثل `greet(pointer: i32, length: i32) -> i32`. إنها تعيد مؤشرًا إلى السلسلة الجديدة في ذاكرة Wasm.
2. الكود اللاصق من جانب الضيف: يقوم `wasm-bindgen` بحقن كود مساعد في وحدة Wasm. يتضمن ذلك دوال لتخصيص/إلغاء تخصيص الذاكرة ومنطقًا لإعادة بناء `&str` في Rust من مؤشر وطول.
3. الكود اللاصق من جانب المضيف (JavaScript): تقوم الأداة أيضًا بإنشاء ملف JavaScript. يحتوي هذا الملف على دالة `greet` مغلفة تقدم واجهة عالية المستوى لمطور JavaScript. عند استدعائها، تقوم دالة JS هذه بما يلي:
   1. تأخذ سلسلة JavaScript (`'World'`).
   2. ترمزها إلى بايتات UTF-8.
   3. تستدعي دالة تخصيص ذاكرة Wasm مصدرة للحصول على مخزن مؤقت.
   4. تكتب البايتات المرمزة في الذاكرة الخطية لوحدة Wasm.
   5. تستدعي دالة Wasm `greet` منخفضة المستوى مع المؤشر والطول.
   6. تتلقى مؤشرًا إلى السلسلة الناتجة مرة أخرى من Wasm.
   7. تقرأ السلسلة الناتجة من ذاكرة Wasm، وتفك ترميزها مرة أخرى إلى سلسلة JavaScript، وتعيدها.
   8. أخيرًا، تستدعي دالة إلغاء تخصيص Wasm لتحرير الذاكرة المستخدمة للسلسلة المدخلة.

من وجهة نظر المطور، ما عليك سوى استدعاء `greet('World')` في JavaScript والحصول على `'Hello, World!'` مرة أخرى. تتم أتمتة كل إدارة الذاكرة المعقدة بالكامل.

دراسة حالة 2: C/C++ و Emscripten

Emscripten هي سلسلة أدوات مترجم ناضجة وقوية تأخذ كود C أو C++ وتترجمه إلى WebAssembly. إنها تتجاوز الروابط البسيطة وتوفر بيئة شاملة تشبه POSIX، تحاكي أنظمة الملفات والشبكات ومكتبات الرسومات مثل SDL و OpenGL.

يعتمد نهج Emscripten لروابط المضيف بالمثل على الكود اللاصق. يوفر العديد من الآليات لقابلية التشغيل البيني:

• `ccall` و `cwrap`: هذه دوال مساعدة JavaScript يوفرها الكود اللاصق لـ Emscripten لاستدعاء دوال C/C++ المترجمة. تتعامل تلقائيًا مع تحويل أرقام وسلاسل JavaScript إلى نظائرها في C.
• `EM_JS` و `EM_ASM`: هذه وحدات ماكرو تسمح لك بتضمين كود JavaScript مباشرة داخل مصدر C/C++ الخاص بك. هذا مفيد عندما تحتاج C++ إلى استدعاء واجهة برمجة تطبيقات المضيف. يتولى المترجم إنشاء منطق الاستيراد اللازم.
• WebIDL Binder & Embind: بالنسبة لكود C++ الأكثر تعقيدًا الذي يتضمن فئات وكائنات، يسمح Embind بكشف فئات وأساليب ودوال C++ لـ JavaScript، مما يخلق طبقة ربط أكثر توجهًا للكائنات من مجرد استدعاءات الدوال البسيطة.

الهدف الأساسي لـ Emscripten غالبًا هو نقل تطبيقات كاملة موجودة إلى الويب، واستراتيجيات روابط المضيف الخاصة به مصممة لدعم ذلك من خلال محاكاة بيئة نظام تشغيل مألوفة.

دراسة حالة 3: Go و TinyGo

توفر Go دعمًا رسميًا للترجمة إلى WebAssembly (`GOOS=js GOARCH=wasm`). يتضمن مترجم Go القياسي وقت تشغيل Go بالكامل (الجدول، جامع القمامة، إلخ) في الملف الثنائي النهائي `.wasm`. هذا يجعل الملفات الثنائية كبيرة نسبيًا ولكنه يسمح بتشغيل كود Go الاصطلاحي، بما في ذلك goroutines، داخل بيئة Wasm المعزولة. يتم التعامل مع الاتصال بالمضيف من خلال حزمة `syscall/js`، والتي توفر طريقة أصلية في Go للتفاعل مع واجهات برمجة تطبيقات JavaScript.

بالنسبة للسيناريوهات التي يكون فيها حجم الملف الثنائي حرجًا ووقت التشغيل الكامل غير ضروري، يقدم TinyGo بديلاً مقنعًا. إنه مترجم Go مختلف يعتمد على LLVM وينتج وحدات Wasm أصغر بكثير. غالبًا ما يكون TinyGo أكثر ملاءمة لكتابة مكتبات Wasm صغيرة ومركزة تحتاج إلى التشغيل البيني بكفاءة مع مضيف، حيث يتجنب الحمل الزائد لوقت تشغيل Go الكبير.

دراسة حالة 4: اللغات المفسرة (مثل Python مع Pyodide)

يمثل تشغيل لغة مفسرة مثل Python أو Ruby في WebAssembly تحديًا من نوع مختلف. يجب عليك أولاً ترجمة مفسر اللغة بأكمله (على سبيل المثال، مفسر CPython لـ Python) إلى WebAssembly. تصبح وحدة Wasm هذه مضيفًا لكود Python الخاص بالمستخدم.

مشاريع مثل Pyodide تفعل ذلك بالضبط. تعمل روابط المضيف على مستويين:

1. مضيف JavaScript <=> مفسر Python (Wasm): هناك روابط تسمح لـ JavaScript بتنفيذ كود Python داخل وحدة Wasm والحصول على النتائج مرة أخرى.
2. كود Python (داخل Wasm) <=> مضيف JavaScript: يكشف Pyodide عن واجهة دالة أجنبية (FFI) تسمح لكود Python الذي يعمل داخل Wasm باستيراد كائنات JavaScript والتلاعب بها واستدعاء دوال المضيف. يقوم بتحويل أنواع البيانات بشفافية بين العالمين.

يسمح هذا التركيب القوي بتشغيل مكتبات Python الشهيرة مثل NumPy و Pandas مباشرة في المتصفح، مع إدارة روابط المضيف لتبادل البيانات المعقد.

المستقبل: نموذج مكونات WebAssembly

الحالة الحالية لروابط المضيف، على الرغم من أنها وظيفية، إلا أن لها قيود. فهي تتمحور في الغالب حول مضيف JavaScript، وتتطلب كودًا لاصقًا خاصًا باللغة، وتعتمد على واجهة تطبيق ثنائية (ABI) رقمية منخفضة المستوى. هذا يجعل من الصعب على وحدات Wasm المكتوبة بلغات مختلفة التواصل مباشرة مع بعضها البعض في بيئة غير JavaScript.

نموذج مكونات WebAssembly هو اقتراح تطلعي مصمم لحل هذه المشكلات وتأسيس Wasm كنظام بيئي لمكونات البرامج عالمي حقًا ومستقل عن اللغة. أهدافه طموحة وتحويلية:

• قابلية التشغيل البيني الحقيقية بين اللغات: يحدد نموذج المكونات واجهة تطبيق ثنائية (ABI) أساسية عالية المستوى تتجاوز الأرقام البسيطة. يقوم بتوحيد تمثيلات الأنواع المعقدة مثل السلاسل والسجلات والقوائم والمتغيرات والمقابض. هذا يعني أن مكونًا مكتوبًا بلغة Rust يصدر دالة تأخذ قائمة من السلاسل يمكن استدعاؤه بسلاسة بواسطة مكون مكتوب بلغة Python، دون أن تحتاج أي من اللغتين إلى معرفة تخطيط الذاكرة الداخلي للأخرى.
• لغة تعريف الواجهة (IDL): يتم تعريف الواجهات بين المكونات باستخدام لغة تسمى WIT (WebAssembly Interface Type). تصف ملفات WIT الدوال والأنواع التي يستوردها ويصدرها المكون. هذا يخلق عقدًا رسميًا يمكن قراءته آليًا يمكن لسلاسل الأدوات استخدامه لإنشاء كل كود الربط الضروري تلقائيًا.
• الربط الثابت والديناميكي: يتيح ربط مكونات Wasm معًا، مثل مكتبات البرامج التقليدية، وإنشاء تطبيقات أكبر من أجزاء أصغر ومستقلة ومتعددة اللغات.
• المحاكاة الافتراضية لواجهات برمجة التطبيقات: يمكن للمكون أن يعلن أنه يحتاج إلى قدرة عامة، مثل `wasi:keyvalue/readwrite` أو `wasi:http/outgoing-handler`، دون أن يكون مرتبطًا بتنفيذ مضيف معين. توفر بيئة المضيف التنفيذ الملموس، مما يسمح لنفس مكون Wasm بالعمل دون تعديل سواء كان يصل إلى التخزين المحلي للمتصفح، أو مثيل Redis في السحابة، أو خريطة تجزئة في الذاكرة. هذه فكرة أساسية وراء تطور WASI (واجهة نظام WebAssembly).

في ظل نموذج المكونات، لا يختفي دور الكود اللاصق، ولكنه يصبح موحدًا. تحتاج سلسلة أدوات اللغة فقط إلى معرفة كيفية الترجمة بين أنواعها الأصلية وأنواع نموذج المكونات الأساسية (عملية تسمى "الرفع" و "الخفض"). ثم يتولى وقت التشغيل توصيل المكونات. هذا يلغي مشكلة N-إلى-N لإنشاء روابط بين كل زوج من اللغات، ويستبدلها بمشكلة N-إلى-1 أكثر قابلية للإدارة حيث تحتاج كل لغة فقط إلى استهداف نموذج المكونات.

التحديات العملية وأفضل الممارسات

أثناء العمل مع روابط المضيف، خاصة باستخدام سلاسل الأدوات الحديثة، تظل هناك عدة اعتبارات عملية.

الحمل الزائد للأداء: واجهات برمجة التطبيقات الضخمة مقابل الثرثارة

كل استدعاء عبر حدود Wasm-المضيف له تكلفة. يأتي هذا الحمل الزائد من آليات استدعاء الدوال، وتسلسل البيانات، وإلغاء التسلسل، ونسخ الذاكرة. يمكن أن يصبح إجراء الآلاف من الاستدعاءات الصغيرة والمتكررة (واجهة برمجة تطبيقات "ثرثارة") عنق زجاجة في الأداء بسرعة.

أفضل ممارسة: صمم واجهات برمجة تطبيقات "ضخمة". بدلاً من استدعاء دالة لمعالجة كل عنصر على حدة في مجموعة بيانات كبيرة، قم بتمرير مجموعة البيانات بأكملها في استدعاء واحد. دع وحدة Wasm تقوم بالتكرار في حلقة ضيقة، والتي سيتم تنفيذها بسرعة تقارب السرعة الأصلية، ثم أعد النتيجة النهائية. قلل عدد المرات التي تعبر فيها الحدود.

إدارة الذاكرة

يجب إدارة الذاكرة بعناية. إذا خصص المضيف ذاكرة في الضيف لبعض البيانات، فيجب أن يتذكر إخبار الضيف بتحريرها لاحقًا لتجنب تسرب الذاكرة. تتعامل مولدات الروابط الحديثة مع هذا جيدًا، ولكن من الضروري فهم نموذج الملكية الأساسي.

أفضل ممارسة: اعتمد على التجريدات التي توفرها سلسلة الأدوات الخاصة بك (`wasm-bindgen`، Emscripten، إلخ) لأنها مصممة للتعامل مع دلالات الملكية هذه بشكل صحيح. عند كتابة روابط يدوية، قم دائمًا بإقران دالة `allocate` مع دالة `deallocate` وتأكد من استدعائها.

التصحيح

يمكن أن يكون تصحيح الأخطاء في الكود الذي يمتد عبر بيئتي لغة ومساحات ذاكرة مختلفة أمرًا صعبًا. يمكن أن يكون الخطأ في المنطق عالي المستوى، أو الكود اللاصق، أو التفاعل الحدودي نفسه.

أفضل ممارسة: استفد من أدوات مطوري المتصفح، التي حسنت باطراد قدراتها على تصحيح أخطاء Wasm، بما في ذلك دعم خرائط المصدر (من لغات مثل C++ و Rust). استخدم التسجيل المكثف على جانبي الحدود لتتبع البيانات أثناء عبورها. اختبر منطق وحدة Wasm الأساسي بمعزل قبل دمجه مع المضيف.

الخاتمة: الجسر المتطور بين الأنظمة

روابط مضيف WebAssembly هي أكثر من مجرد تفصيل تقني؛ إنها الآلية ذاتها التي تجعل Wasm مفيدًا. إنها الجسر الذي يربط عالم حسابات Wasm الآمن وعالي الأداء بالقدرات التفاعلية الغنية لبيئات المضيف. من أساسها منخفض المستوى من الاستيراد الرقمي ومؤشرات الذاكرة، شهدنا صعود سلاسل أدوات لغوية متطورة توفر للمطورين تجريدات مريحة وعالية المستوى.

اليوم، هذا الجسر قوي ومدعوم جيدًا، مما يتيح فئة جديدة من تطبيقات الويب والخوادم. غدًا، مع ظهور نموذج مكونات WebAssembly، سيتطور هذا الجسر ليصبح تبادلًا عالميًا، مما يعزز نظامًا بيئيًا متعدد اللغات حقًا حيث يمكن للمكونات من أي لغة التعاون بسلاسة وأمان.

إن فهم هذا الجسر المتطور ضروري لأي مطور يتطلع إلى بناء الجيل القادم من البرامج. من خلال إتقان مبادئ روابط المضيف، يمكننا بناء تطبيقات ليست أسرع وأكثر أمانًا فحسب، بل أيضًا أكثر نمطية وقابلية للنقل وجاهزة لمستقبل الحوسبة.